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(54) Title: METHOD FOR TRANSMITTING ASYNCHRONOUS DATA IN A HOME NETWORK 
(57) Abstract 



The invention concerns a method for trans- 
mitting data in a home communication network. 
The network comprises a first device and a second 
device, wherein said first device includes means 
to produce a data packet and said second device 
includes means to use said data packet. The in- 
ventive method is characterised in that it com- 
prises the steps of: opening a connection between 
said first device and said second device; having 
said second device allocate a message buffer to 
said connection, said second device communicat- 
ing the message buffer size to said first device; 
having said first device transmit said data packet 
to said second device, wherein said data packet 
is split and sent as pay load in messages, where 
the size of the payloads is smaller or equal to 
said message buffer size. The invention applies 
to home network communications. 
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Method for transmitting asynchronous data in a home network 

5 The specification 'Home Audio/Video interoperability architecture 

version 0.8\ also called 'HAVP architecture, was disclosed on May 15, 1998 on 
the WEB sites of at least the following companies: Sony, Philips, Toshiba, 
Sharp and Hitachi. 

This specification describes the implementation of a home network 
10 comprising consumer electronics devices and computing devices, and 
compatible with the IEEE 1394 1995 serial bus and the IEC 61883 interface 
standards. 

The HAVi specification version 0.8 describes in its sections 3.2 and 
5.2 an inter-device communication system referred to as the 'Messaging 

is System 1 . The Messaging System, sometimes also called the 'Message Passing 
System', is a software object (a 'software element' according to the HAVi 
terminology) present in some device types of the network. It possesses an 
application programmable interface, comprising a number of functions, which 
can be accessed by a software element to send a message to another software 

20 element. When a software element calls a function of another software element 
of another device, the function called is mapped into a Messaging System 
message. 

Messages use a predefined format which is described in section 
3.2.1. of the HAVi document. A message contains two bytes defining the length 
25 of the message payload. The maximum length of a message is thus a little over 
64 Kb: the maximum payload, to which the length of the header information is 
added. 

The Messaging System of HAVi version 0.8 is well adapted for 
performing function calls and managing software element identifiers in the 

30 network. The inventors have recognized the following problem with the 
proposed architecture: when a sending software element sends a message to a 
receiving software element, the Messaging System does not take into account 
the memory capacity of the receiving software element. The receiving software 
element may encounter problems to process a huge amount of data if the 

35 buffer allocated to the communication by the receiving software element is not 
adequate. In other words, the HAVi 0.8 document does not enable the receiving 
software element to control the amount of data it receives. 
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The object of the invention is a method for transmitting data in a 
home communication network comprising a first device and a second device, 
wherein said first device includes means to produce a data packet and said 
second device includes means to use said data packet, said method being 
5 characterised in that it comprises the steps of: 

- opening a connection between said first device and said second 

device; 

- having said second device allocate a message buffer to said 
connection, said second device communicating the message buffer size to said 

10 first device; 

- having said first device transmit said data packet to said second 
device, wherein said data packet is split and sent as payload in messages, 
where the size of the payloads is smaller or equal to said message buffer size. 

is The receiving device specifies the size of its message buffer at the 

beginning of the transmission, and the sending device takes into account this 
value in order to maintain a limited payload size. 

The word 'device' is not limited in its significance to a physical 
device. It comprises among others software objects, and in particular 'software 

20 elements' as defined by the HAVi 0.8 document. 

According to a particular embodiment of the invention, said payloads 
have a first maximum length independent of said first and second devices and 
wherein a second maximum length dependent of said second device is 
25 constituted by said message buffer size, the shortest of said first and second 
maximum lengths being retained for sending messages to said second device. 

The first maximum message size is that given by the specification in 
itself: for instance, HAVi 0.8 gives 64 kilobytes as the maximum message size. 
30 The second maximum message size is that defined within the connection, i.e. 
the message size of the receiving device. This message size has to be used 
only in connection with messages sent to that particular receiving device, and 
through the particular connection. 

The invention thus solves a problem inherent to the network 
35 presented in the HAVi 0.8 document, while being compatible with this 
document, and in particular with the Messaging System. 
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Other characteristics and advantages of the invention will appear in 
the description of a non-limiting embodiment, described with the help of the 
enclosed figures, among which: 

- figure 1 is a block diagram of a home network; 

5 - figure 2 is a block diagram of a device in the home network of figure 

1; 

- figure 3 is a diagram of an example of the software objects and 
layers implemented in the device of figure 2; 

- figure 4 is a diagram of message exchanges between an entity 
10 producing a stream ('producer') and an entity receiving that stream 

('consumer'), in the case the producer takes the initiative to send the stream; 

- figure 5 is a diagram similar to figure 4, but in the case where the 
consumer takes the initiative to request a stream from the producer; 

- figure 6 is a diagram of an exchange between two entities which 
15 are both producer and consumer in the frame of a same connection. 

The present description uses a terminology defined in the following 
document, to which one should also refer for further details about the home 
network architecture: 'The HAVi Architecture - Specification of the Home 
20 AudioA/ideo interoperability (HAVi) Architecture' of May 11, 1998 Version 0.8 
and publicly disclosed on May 15, 1998 on the WEB sites of at least the 
following companies: Sony, Philips, Toshiba, Sharp and Hitachi. 

Figure 1 is a diagram of an example of a HAVi-compliant home 
25 network comprising all four types of devices defined by the HAVi 0.8 
specification. The home network comprises a communication bus, which is a 
IEEE 1394 1995 serial bus according to the present example. To this bus are 
connected a digital television, a digital receiver/decoder, a modem, a Digital 
Video Disc recorder/player (DVD) and a Videocassette Recorder (VCR). The 
30 television receiver is a Full AudioA/ideo (FAV) device, which is the device type 
having the most functionalities according to the HAVi specification. In particular, 
the FAV type device has the capacity to execute HAVi runtime code. The 
television receiver can thus host the software to control the VCR, which in the 
present case is a Legacy device, i.e. a device having no HAVi functionality. The 
35 Legacy device is connected directly to the Full AudioA/ideo device, since it 
does not have a bus connector or the necessary means to communicate on the 
bus. The digital decoder and the modem are Intermediate Audio/Video (IAV) 
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devices, which have many of the features of the FAV device, but not the 
capability to download software to control other devices. Such software may 
nevertheless be resident in an 1AV device. Lastly, the DVD player is a Basic 
AudioA/ideo device, which does not have the means to run HAVi code, but has 

5 at least the capacity to connect to the communication bus and to communicate 
with a IAV or FAV device which runs the software interface between the HAVi 
environment and the Basic AudioA/ideo device's own environment. 

Figure 2 is a block diagram of the television receiver's components 
related to its HAVi functionalities. The television receiver 1 contains a 

10 microprocessor 2, connected to a RAM memory 3 and a reprogrammable ROM 
memory 4 through an internal bus 7. The ROM is used to store the receiver's 
software elements and other code for managing the device's functionalities 
executed by the microprocessor. The television receiver also contains a 
connection 5 to the IEEE 1394 bus, the connection comprising a physical/link 

15 circuit (and the software required for the asynchronous transaction and bus 
management layers. The television receiver also comprises a connector 6 
destined to control and exchange AudioA/ideo streams with a specific device, in 
this case the VCR of figure 1 . 

Figure 3 shows the organisation of software objects ('software 

20 elements' according to the HAVi terminology) in the television receiver, and 
more generally in a FAV-type device. 

The television receiver hosts a number of applications and device 
control applications which interact with the following software elements through 
corresponding application programmable interfaces: 

25 - a 1394 Communication Media Manager, which allows other 

software elements to perform asynchronous and isochronous communication 
over the IEEE 1394 bus, 

- a Message Passing System, for exchanging messages with other 
software elements, 

30 - an Event Manager for managing object state changes, 

- a Stream Manager for managing Audio/Video data streams 
between functional components, such as a tuner and a recording device, 

- a Registry, which keeps a list of local software elements and its 
identifiers and manages communication with distant registries, 

35 - a Device Control Module Manager (DCMM), for loading or deleting 

Device Control Modules (DCM), 

- a number of either resident or uploaded Device Control Modules. 
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The resident application of figure 3 is in the present case an 
Electronic Program Guide, while one of the Device Control Modules (DCMs) 
has been installed to control the VCR of figure 2, and another DCM has been 
5 downloaded from the DVD player. 

A device control module may control one or more Functional Control 
Modules, also called FCMs. An FCM is a software element which gives control 
over a specific function of a device through a well known function set, 
comprising groups of functions called Application Programmable Interfaces, or 
10 APIs. In a digital television receiver/decoder, FCM APIs would typically be 
dedicated to the control of the tuner and the video/audio decoder. 

According to the present embodiment, an Asynchronous Data API is 
defined. This API, or a part thereof, is to be included into the FCMs which 
require the capability of managing the transfer of asynchronous data streams 
15 between a producer and a consumer. 

The terms 'producer' and 'consumer' are used to designate the 
capability of a device or functional component to produce an asynchronous 
stream or to receive such a stream. Consumers and producers may be storage 
devices, but this is not necessarily so. 
20 A digital stream demultiplexer demultiplexing service information is a 

producer. A recording device (for instance a memory, a magneto-optical disk, a 
hard disk or a digital video cassette recorder) can also be a producer. A piece 
of software generating or processing data may also be a producer. 

Examples of consumers can also be given: a recording device 
25 playing back information, a printer or a display device. 

The notions of producer and consumer are not exclusive: some 
devices or functional components may have both functions within a same 
connection. An example of such a device is a modem connected to the public 
switched telephone network for accessing internet services. Seen from the 
30 HAVi network, the modem can act as a consumer, i.e. by accepting data from a 
client application for transmission to an internet server, or it may act as a 
producer, when transferring data from the internet server to the client 
application. The client application is also both a producer and a consumer in 
this case. 

35 The term 'asynchronous data stream 1 is used to make a distinction 

with the 'isochronous data streams', i.e. the audio and video streams handled 
by the Stream Manager defined by the HAVi document. Typically, 
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6 



asynchronous data consists in data corresponding to a picture, a file or 
program code. An FCM implementing the functions explained in detail below 
will remain compatible with the Messaging System (as defined in the HAVi 
version 0.8 document) while correcting the deficiencies described in the 
5 introduction. 

An FCM can manage one or more containers, a container being the 
general term to designate a consumer, a producer or an entity having both 
functions. If an FCM contains more than one container, then each container is 
identified by a unique label. Such a label is redundant if only one container is 
10 present, but can, according to a variant of the invention, nevertheless be 
implemented for system uniformity reasons. 

The Asynchronous Data API is defined by the parameters and 
functions given below. Depending on whether an FCM is simply a consumer, a 
15 producer or both, the appropriate subsets of functions have to be implemented. 

The term 'in* used in the function definitions defines parameters 
which are passed by the software element calling the function to the software 
element which receives the function call, while the term 'out* defines parameters 
sent back by the software element receiving the function call. 

20 

(a) The FileLoc parameter 

This parameter indicates whether a message from a producer to a 
consumer is the first message, an intermediate message or the last message of 
a contiguous series of messages. The conditions of use of such series of 
25 messages will be explained be described later in relation with figures 4 to 6. 

The parameter is defined as follows: 

enum FileLoc { START, NEXT, MIDDLE}; 

(b) The Container parameter 

30 It defines the characteristics of a container. For example, a container 

containing program files will be defined by its identifier ('ioid'), the names of files 
it contains, the file types and the sizes of the files. 
The parameter is defined as follows: 
struct Container { 
35 ioid; 

characteristics; 

} 
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(c) The OpenRead function 

This function is implemented within an FCM which is only a 
producer. It is called by a consumer to request the transfer of an asynchronous 
stream from a container . It is defined as follows: 



Status loStream::OpenRead( 

in any ioid, 

in long message_buffer__size, 
in OperationCode opCode, 
out short cid 

) 



'Status 1 is the type of the function return value. 

The following parameters are used by the OpenRead function: 

- ioid : This is the identifier of the container to be opened. It is not 
mandatory if the FCM which implements the function has only one container 
and will be ignored by that FCM if nevertheless present in the function call. 

- message_buffer__size : This parameter indicates the maximum size 
of a message accepted by the consumer, excluding the messaging system 
overhead (i.e. the header and other data related to the messaging system 
layer). The producer will take into account that parameter to determine the 
length of its message payloads to the consumer. Preferably, the length of the 
payloads will be equal to the message buffer size of the consumer. 

The message buffer size is either fixed or can be allocated 
dynamically by the calling software element on the basis of available memory 
resources when the connection is to be established. For the OpenRead 
function, the consumer takes the initiative to establish the connection, and so 
the message buffer size passed as a parameter in the OpenRead function is 
the size of the consumer message buffer. 

- opCode : this parameter is a code the producer will use to send the 
stream to the consumer. This operation code identifies a function of the 
consumer which the producer has to call to forward a response to the client. 
This parameter is set by the consumer. The operation code uniquely identifies a 
function within a software element. In this case, it is the 'Write' function, as 
defined below. The unique address of a function in the network thus comprises 
the , SEID' identifier and the operation code . 
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- cid : This parameter identifies a given connection between the 
producer and the consumer, since there may be more than one such 
connection. Its value is defined by the producer, and is different from all other 
such identifiers used by the same producer at a given moment, in order to 
5 uniquely identify each connection. 



One of the following values is returned by the 'OpenRead' function 



call: 



'0* if the call has been a success 
10 T if the container identifier was not correct 

'2* if the container could not be accessed. This can happen for 
example if too many read accesses are made over several connections at the 
same time. 

15 (d) The Open Write function 

This function is implemented in FCMs which are only consumers. It 
enables a producer to send an asynchronous stream to container of a 
consumer's FCM. . 

It is defined as follows: 
20 Status loStream::OpenWrite( 

in any ioid, 

out long message_buffer_size, 
out short cid 

25 ) 

The following parameters are used, in addition to those which have 
already been defined: 
- ioid, 

30 

message_buffer_size : indicates the maximum size of a message 
payload accepted by the consumer. The producer will take into account that 
parameter during the sending of the data and until a close request. 

cid : This parameter identifies the connection. In the case of the 
35 OpenWrite function, it is the called FCM which defines the value of the cid 
parameter. 

The function returns one of the following values: 
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'0' if the function call is successful, 

T if the container identifier 'ioid' sent in the function call is not 

correct, 

, 2' if the container identified by the 'ioid' identifier cannot be 

5 accessed. 

(e) The Open function 

This function is implemented in FCMs which act both as a consumer 
and as a producer in the frame of a same connection. 

It enables a consumer/producer to receive/send an asynchronous 
stream from/to a container. 

It is defined as follows: 
Status loStream::Open( 

in any ioid, 

in long message_buffer_size_client, 
in OperationCode opCode, 
out long message_buffer_size_FCM, 
out short cid 
) 

The following parameters are used : 

- ioid, 

- messagejDuffer_size_client : This parameter indicates the 
25 maximum size of a message accepted by the client application which calls the 

FCM function. When the called FCM is a producer, it will take that parameter 
into account for the sending of the data to the consumer (i.e. the client 
application) and until a close request. 

- message_buffer_size_FCM This parameter indicates the 
30 maximum size of a message accepted by the FCM. When the clients 

application acts as a producer, it will take that parameter into account during 
the sending of the data to the consumer (i.e. the FCM) and until a close 
request. 

- opCode : this parameter is the code which the FCM will use to send 
35 the asynchronous stream to the client application (which will act as a 

consumer). This operation code identifies a function of the client application API 
which the producer has to call to forward asynchronous data to the client. In 



15 
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this case, it is the 'Write 1 function, as defined below. The unique address of a 
function in the network thus comprises the 'SEID' identifier and the operation 
code . 

cid : This parameter identifies the connection. It is determined and 
5 delivered by the FCM. 

The function returns one of the following values: 
'0' if the function call is successful, 
* T if the container identifier 'ioid' sent in the function call is not 

correct, 

10 '2' if the container identified by the 'ioid' identifier cannot be 

accessed. 

(e) The Write function 

The Write function is the function which has to be called by a 
is producer to transfer data to a consumer. The producer has to wait for the return 
value of the Write function before calling this function a new. 

This function is implemented at the consumer side. Its operation 
code is a well-known operation code when the FCM acts as a consumer, 
because the operational codes of the functions of the Asynchronous Data API 
20 are predetermined. In case a client application acts as a consumer, the 
operation code is sent to a producer as a parameter through the OpenRead or 
the Open function call by a consumer, because the Asynchronous Data API is 
not necessarily implemented by the client application. It is assumed here that 
the client application implements the Write function, although any proprietary 
25 function achieving similar results may be used. 

The Write function is defined as follows: 

loStream::Write 

Prototype 

30 Status loStream:: Write ( 

in cid, 

in FILELOC where, 

in sequence <byte> data, 

) 



In addition to the parameters which have already been defined for 
the other functions, the following parameters are used by the Write function: 
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- where : This parameter informs the consumer that a message is the 
first, the last or an intermediate message among a series of messages for 
transferring a stream, 

- data : This is the payload of the message, i.e. a part of the stream 
5 to be transferred. 

The Write function returns one of the following return values: 
'0' if the consumer requests further messages, 

T if the consumer needs to inform the producer that it should abort 
io the transfer. 

(0 The Dir function 

This function returns the list of identifiers of containers of an FCM. If 
the FCM manages only one default container, then the function need not be 
15 implemented. 

According to a variant of the present embodiment, this function also 
returns other characteristics of each container (such as for example type of 
storage element, total space available, free space available, list of files etc..) 

20 The function is defined as follows: 

loStream::Dir 
Prototype 
void loStream::Dir( 

out sequence <Container> list 

25 ) 

The Mist' parameter is the list of containers managed by the FCM. As 
described above, a container is identified by its Moid' identifier. The list can be 
empty. This means that the FCM handles only one container. 

30 

(g) The 'Close 1 function 

This function enables a consumer or a producer to close a previously 
opened connection, identified by the 'cid' parameter. The connection can only 
be closed by the client application which opened it. 
35 A software element does not necessarily need to close a connection 

after a stream transfer has been achieved. It can keep the connection open and 
transfer further streams through that connection. 
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The function prototype is defined as follows: 
Status IOStream::Close( 

in long cid 

) 

The only parameter is the 'cid' parameter, i.e. the identifier of this 
connection. 

The receiving FCM acknowledges with one of the following status 

values: 

0: The connection has been closed successfully, 

1: The transmitted value of the 'cid' parameter is unknown. 

Figure 4 illustrates the message flow between a consumer and a 
producer when the producer takes the initiative to send a stream. 

A producer, for example the decoder of figure 1, requests its 
Messaging System to call the OpenWrite function of a consumer, for example 
the display of the digital television receiver of figure 1, in order to prepare the 
display to show a still picture which the decoder has demultiplexed and 
decompressed. The decoder has obtained the identifier of the Display FCM 
from its local Registry service, by requesting a list of all display devices in the 
network, and has decided to use the display of the digital television receiver. 
For this purpose, the Display FCM run by the Full Audio/Video device of the 
network of figure 1 comprises the required functions from the Application 
Programmable Interface defined above, i.e. the Open, Write and Close 
functions. 

More details about the Registry service are given in the French 
patent application FR 9805110 filed on April 23, 1998 in the name of 
THOMSON multimedia. 

The consumer acknowledges the request for opening a connection 
by returning the value '0\ and passing the corresponding parameter values, i.e. 
the connection identifier 'cid 1 , the size in bytes of the message buffer allocated 
to this connection and the operational code of the Write function, which is in 
principle not known by the producer. The producer will then proceed to transfer 
its data, adequately distributed over a number of messages in such a way that 
none of the message payloads is longer than the specified message buffer 
size. 
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The producer will first make a Write function call in which the 'where 1 
parameter has the value START, using the operational code previously 
received from the consumer. The 'START' value indicates that the message is 
the first message of a series of messages in which a piece of data greater than 
5 the consumer's message buffer size is transferred. According to the preferred 
embodiment, the producer strives to use for each of its message payloads the 
maximum message length authorised by the consumer's message buffer size in 
order to reduce the overall number of messages required. In other words, the 
payload size is equal to the specified consumer buffer size if enough data 
10 remains to be sent. If the buffer size specified by the consumer is greater than 
the limit defined by the HAVi document (i.e. 64 kilobytes in the version 0.8), 
then the payload size of the messages is limited to that size. 

The producer will also include part of the data to be transferred into 
this first message. Subsequent messages will use the value 'NEXT' for the 
15 'where 1 parameter, to indicate intermediate messages in the series of 
messages. The last message will use the 'END' value. 

The producer will send messages only after having received a proper 
acknowledgement ('0' return value') for each Write function call it performs. 

When all data has been transferred, the producer calls the Close 
20 function to close the connection with the consumer. 

Figure 5 illustrates the case where a consumer takes the initiative to 
open a connection, calling the 'OpenRead' function of a producer's FCM. Apart 
from the parameters which differ between the OpenRead function and the 
25 OpenWrite function, the mechanism is similar to the one explained in 
connection with figure 4. 

Figure 6 illustrates the case in which a consumer-producer client 
application initiates a full duplex connection with a consumer-producer FCM. 
30 According to the present embodiment, the FCM manages a modem associated 
with a single container. 

The client application opens the connection with the FCM providing 
as a parameter its maximum buffer size to handle incoming messages.. In 
response, the FCM initialises the modem, connects to a given server using 
35 predetermined settings (phone number, connection name, password...) 
confirms the opening of the connection to the client application (by transmitting 
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the '0' status value) and transmits, among other parameters, its maximum 
message buffer size and the identifier of the connection (cid),. 

The client's application then sends a first request (which according to 
the present example fits into one message payload to the FCM. The FCM 

5 forwards the payload content through the modem access and acknowledges 
the transmission to the client application. The server processes the request and 
sends it back a response. The FCM receives the response flow and forwards it 
to the client application using several messages, distributing the response over 
the payloads of the messages according to the maximum buffer size of the 

10 client application. The transfer of data continues until all data is transferred. The 
communication between the client application and the FCM continues 
according to a predefined protocol between the client application and the 
remote server. 

According to this protocol, the client application hen closes the 
15 connection. 



European patent application 98402384.6 filed on September 28, 
1998 in the name of the Applicant and whose priority is claimed concerns an 
20 internet access functional component module. 
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Claims 

1. Method for transmitting data in a home communication network 
5 comprising a first device and a second device, wherein said first device 

includes means to produce a data packet and said second device includes 
means to use said data packet, said method being characterised in that it 
comprises the steps of: 

- opening a connection between said first device and said second 

10 device; 

- having said second device allocate a message buffer to said 
connection, said second device communicating the message buffer size to said 
first device; 

- having said first device transmit said data packet to said second 
is device, wherein said data packet is split and sent as payload in messages, 

where the size of the payloads is smaller or equal to said message buffer size. 

2. Method according to claim 1, characterised in that said payloads 
have a first maximum length independent of said first and second devices and 

20 wherein a second maximum length dependent of said second device is 
constituted by said message buffer size, the shortest of said first and second 
maximum lengths being retained for sending messages to said second device. 

3. Method according to claims 1 or 2, characterised in that said 
25 connection is opened by said first device through a function call sent to said 

second device for writing data to said second device. 

4. Method according to claims 1 or 2, characterised in that said 
connection is opened by said second device through a function call sent to said 

30 first device for reading data from said first device. 

5. Method according to one of the claims 1 to 4, characterised in that 
said first device comprises at least one data storage element for storing said 
data packet. 



35 
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6. Method according to claim 5, characterised in that said device 
comprises more than one storage element, each of said storage elements 
being identified by an identifier. 



5 7. Method according to one of the claims 1 to 6, characterised in that 

said second device comprises at least one data storage element for storing 
said data packet. 
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response to an invitation under Article 14 are referred to in this report as "originally filed" and are not annexed to 
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Claims, No.: 

1 -7 as originally filed 

Drawings, sheets: 

1 /3-3/3 as originally filed 

2. The amendments have resulted in the cancellation of: 

□ the description, pages: 

□ the claims, Nos.: 

□ the drawings, sheets: 

3. □ This report has been established as if (some of) the amendments had not been made, since they have been 

considered to go beyond the disclosure as filed (Rule 70.2(c)): 

4. Additional observations, if necessary: 
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V. Reasoned statement under Article 35(2) with regard to novelty, inventive step or industrial 
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1. Statement 



Novelty (N) 



Yes: 
No: 



Claims 
Claims 



Inventive step (IS) 



Yes: 
No: 



Claims 
Claims 
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Industrial applicability (IA) 



Yes: 
No: 



Claims 
Claims 



1-7 



2. Citations and explanations 
see separate sheet 

VII. Certain defects in the international application 

The following defects in the form or contents of the international application have been noted: 
see separate sheet 

VIII. Certain observations on the international application 

The following observations on the clarity of the claims, description, and drawings or on the question whether the 
claims are fully supported by the description, are made: 

see separate sheet 
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Re Item V 

Reasoned statement under Article 35(2) with regard to novelty, inventive step or 
industrial applicability; citations and explanations supporting such statement 

1 . Reference is made to the following documents cited in the International Search 
Report: 

D1 : EP-A-0 604 166 (SONY CORP), 29 June 1994 (1994-06-29), 

D2: SONY PHILIPS HITACHI SHARP MATSUSHITA THOMSON TOSHIBA 
GRUNDIG: 'Specification of the Home Audio/Video Interoperability 
Architecture 1 THE HAVI ARCHITECTURE, 11 May 1998 (1998-05-11), 
pages 25-29, XP0021 15566 . 

2. The subject-matter of independent claim 1 does not involve an inventive step 

in the sense of Article 33(3) PCT for the following reasons: 

Document D1, according to the main features of claim 1, discloses a method for 
transmitting data in a home communication network (column 1, lines 1-10) 
comprising a first device and a second device (column 7, lines 15-19: "plurality of 
devices"), wherein said first device includes means to produce a data packet 
(column 7, lines 42-51 : "a device [...] being adapted to transmit [...] a transmit 
signal [..,] in which one frame [...] consists of an address field [..J, a control field 
[...] and a data field 1 ) and said second device includes means to use said data 
packet (column 8, lines 4-6), whereby said method comprises the step of having 
said first device transmit said data packet to said second device, wherein said 
data packet is split and sent as payload in messages (column 7, lines 52-54: 
"transmitting data [...] in a manner divided into a plurality of frames"). 

The subject-matter of claim 1 therefore differs from the method described in 
document D1 in that it adds the steps of 

• opening a connection between said first device and said second device; 

• having said second device allocate a message buffer to said connection, 
said second device communicating the message buffer size to said first 
device; 

• and determining the size of the payload as smaller or equal to the message 
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buffer size from the second device. 

The problem to be solved by the present invention may therefore be regarded as 
how to adapt the size of the payload to prevent the saturation of the second 
device with the transmitted data. This is a well known problem of flow control in 
telecommunication system. 

The opening of a connection for the communication between two devices is well- 
known in the art. For example, the HAVI Architecture from which document D2 is 
extracted, already discloses such a communication method. Then, when the 
person skilled in the art encounters the problem of saturation of the second 
device, it is obvious for him to add a additional message in its message set to 
inform the emitter of the buffer size of the receiver, so that the emitter does not 
send messages greater than the message buffer size of the receiver. This is an 
obvious solution for flow control. 

The skilled person, therefore, being aware of the disclosure of document D1 can 
apply common general knowledge of the art (for example, the HAVI Architecture 
and flow control mechanism) and arrive at the method of claim 1 . 

3. Furthermore, the subject-matter of dependent claims 2-7 is, when interpreted 
with the help of the description, either derivable from the above cited documents 
or concerns simple embodiments without inventive merit in themselves. 

Therefore, these claims do not add inventive matter to the claims upon which 
they are dependent. 

In particular: 

In claim 2, it is well-known for a person skilled in the art that a message usually 
have a maximum length, for example for implementation reason (in secured 
operative systems, the dynamic memory allocation is usually forbidden, so that all 
data are size limited). It is also the case in the HAVI 0.8 specification, as indicated 
by the Applicant in the description page 2, line 29. Then to retain the minimum 
size for the message size is obvious for a skilled person. 
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In claims 3 and 4, the way the connection is opened is already known from the 
HAVI specification. 

In claims 5-7, the use of data storage element for storing data packet is a well- 
known knowledge in telecommunication systems (for example, hard-disc, 
magnetic tapes). Additionally, the additional features in the method claims 5-7 
relate to technical features defining an apparatus rather than step of a method. 
Namely, these claims define more clearly the first and second devices since they 
comprises one or more data storage element for storing the data packet. But no 
steps are defined, so that they cannot contribute to the inventive activity of the 
method. 



Re Item VII 

Certain defects in the international application 

1 . The independent claims do not correctly reflect the known prior art in the two-part 
form in accordance with Rule 6.3(b) PCT, with those features known in combi- 
nation from the prior art being placed in the preamble (Rule 6.3(b)(i) PCT) and 
with the remaining features being included in the characterising part (Rule 
6.3(b)(ii) PCT). 

2. The document D1 reflecting the prior art is not introduced and briefly discussed in 
the description (Rule 5.1 (a)(ii) PCT). 

3. Reference signs, in parentheses, are missing after each features in the claims 
according to Rule 6.2(b) in order to facilitate the understanding of the claims. 

4. Some clerical errors are present in the description: 

• page 4, lines 15-18 the opening parenthesis is not closed in this paragraph, 
page 13, line 33: instead of 

• page 14, line 14: " hen" instead of "then". 

The numbering of the paragraph from page 9 is not correct. The letter (e) is used 
for two consecutive paragraphs ("The Open function" and "the Write function"). 



Form PCT/Separate Sheet/409 (Sheet 3) (EPO- April 1997) 



INTERNATIONAL PRELIMINARY international application No. PCT/EP99/03953 
EXAMINATION REPORT - SEPARATE SHEET 



5 Th e reference to application numbers FR 98051 10 (page 12, line 27) and EP 
98402384.6 (page 14, line 18) is not allowed since these number are not 
accessible to the public. Note that the application EP 98402384.6 has been 
published with the publication number EP 0 964 558. 

6. There are also some inconsistency in the description and the drawings: 

page 4, line 28: there is no element in figure 3 with the name of "Message 
Passing System", 

The description of the enumeration FileLoc (page 6, line 27) defines 3 values 
"START, NEXT, MIDDLE". But the value "END" (page 13, line 15) is also 
mentioned for the parameter where (of the Write function) which only 
accepts FileLoc value (page 10, lines 27-34). 



Re Item VIII 

Certain observations on the international application 

The subject matter of dependent claim 6 is not clearly defined in the sense of Article 6 
PCT. The reference to "said device? is ambiguous, since there is not only one device 
but at least two devices - the first and the second ones - which play different roles. 
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